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Sielski  1 

The  US  Army  has  been  trying  to  automate  its  tactical  command  and  control 
process  since  the  beginning  of  the  last  decade.1  Pursuit  of  this  goal  took  the 
form  of  an  acquisition  program  for  the  development  and  fielding  of  an 
integrated  hardware/software  system  designed  to  meet  the  requirements  of 
deployed  tactical  units.  Known  as  the  Maneuver  Control  System,  or  MCS,  this 
automated  system,  has  yet  to  be  fielded  in  any  useful  form  to  Army  units  after 
over  10  years  of  developmental  effort.  This  paper  illuminates  the  Department 
of  Defense  (DOD)  acquisition  process  as  it  applies  to  MCS  and  shows  how  the 
interests  of  DOD  officials  became  arrayed  against  Army  intentions  to  develop 
and  field  the  MCS  system.  Allison’s  "bureaucratic  politics"  model  will  guide 
the  analysis  and  illustrate  some  reasons  for  the  fielding  delay. 

The  Maneuver  Control  System  is  a  software  application  designed  to 
automate  the  command  and  control  information  process  for  the  force  level 
commander  and  his  staff  both  in  a  tactical  environment  and  in  garrison.2  The 
software  is  designed  to  run  on  Army  standard  computer  hardware,  itself  in  a 
parallel  development  effort.  MCS  is  envisioned  to  gather,  correlate  and  focus 
battlefield  information  from  the  five  functional  areas  indigenous  to  Army 
operations.  These  functional  areas  are;  Maneuver,  Fire  Support,  Air  Defense, 
Intelligence,  and  Combat  Service  Support  or  logistics.  Tactical 
communications  links  provide  the  connectivity  between  MCS  computers 
allowing  them  to  function  in  a  network.3 

As  with  any  acquisition  program  specific  steps  are  required  to  bring  a 
system  from  a  concept  to  a  working  piece  of  hardware.  First,  the  concept  must 
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be  refined  into  a  precise  document  describing  the  system  requirements.  This 
requirements  document,  after  gaining  departmental  approval,  must  then  be 
expanded  into  a  technical  specification,  which,  after  solicitation,  can  be 
translated  into  a  development  contract.  Once  prototypes  are  produced,  a 
detailed  series  of  tests  are  conducted  to  determine  if  the  capabilities  delivered 
meet  the  system  requirements.  If  the  correlation  between  capabilities  delivered 
and  desired  requirements  is  satisfactory,  a  decision  is  made  authorizing 
production  in  preparation  to  field  the  system.4 

From  it’s  beginning,  the  MCS  program  has  undergone  an  evolutionaiy 
development  process.  The  initial  requirement  for  the  system  was  approved  in 
1982. 5  Full  Mil-Spec  hardware  and  compatible  software  had  been  developed 
and  fielded  on  a  very  limited  basis  in  Europe  in  the  early  1980’s.6  The 
rudimentary  capabilities  of  this  first  iteration  of  MCS  were  improved  as 
technology  improved.  Advancing  computer  technology  and  evolving 
requirements  precipitated  the  development  of  software  upgrades  that  were 
fielded  on  more  capable,  semi-commercial  hardware  in  the  late  1980’s.7  By 
1990,  virtually  all  active  Army  divisions  had  been  issued  this  second  iteration 
of  MCS. 

It  is  important  to  note  that  the  capabilities  fielded  with  the  second  iteration 
were  still  considered  crude.  Many  units,  after  their  appetites  for  automated 
command  and  control  were  whetted  by  MCS,  grew  impatient  when  presented 
with  what  the  growing  personal  computer  industry  had  available.  In  some 
cases,  these  units  began  to  use  local  funds  to  purchase  and  experiment  with 
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commercial  offerings.  The  Army  recognized  the  dangers  inherent  in  disparate 
automated  systems  incapable  of  sharing  information  on  a  large  scale. 

The  Army  strategy  had  always  been  to  replace  the  original  MCS  version 
(Block  1)  and  the  second  fielded  version  (Block  2)  with  a  much  more  capable 
system  known  as  Block  3.  Software  for  this  version  would  run  on  new  Army 
standard  computer  hardware  under  separate  development.8  Although  the  need 
to  get  version  3  fielded  was  pressing,  the  development  time  was  now  becoming 
an  issue.  Users  had  been  promised  a  fully  functional  MCS  for  almost  10 
years.  Unfortunately,  as  the  complexity  of  the  software  grew,  the  system’s 
development  slowed.  Perhaps  for  this  reason,  the  Office  of  the  Secretary  of 
Defense  (OSD)  assumed  oversight  of  the  MCS  program  from  the  Army  in  July 
1992. 9 

An  already  complex  acquisition  process  gains  complexity  by  an  order  of 
magnitude  when  direct  oversight  of  a  system’s  development  is  elevated  from 
the  originating  service  to  OSD  itself.  According  to  DOD  Instruction  5000.2, 
OSD  oversight  becomes  mandatory  when  a  program  exceeds  specific  total 
dollar  amounts  for  both  research  &  development  and  acquisition.10  Even 
though  MCS  funding  does  not  approach  those  specified  dollar  amounts,  the 
program  was  nevertheless  elevated  to  OSD  oversight  by  order  of  the  Defense 
Acquisition  Executive.  Despite  the  developmental  teething  problems  MCS  was 
already  experiencing,  and  the  resultant  user  frustration,  this  action  enmeshed 
the  MCS  program  in  a  bureaucratic  paper  chase  which  continues  apace. 

Although  no  additional  paperwork  is  generated  on  the  varied  aspects  of  the 
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systems’  development  by  the  addition  of  OSD  oversight,  the  bureaucracy  of 
the  OSD  staff  now  had  the  license  to  drape  their  interpretations  of  regulation 
over  every  aspect  of  the  acquisition  process.  Pertaining  to  MCS,  the  interested 
offices  of  OSD  include  the  Defense  Acquisition  Executive  (DAE),  the  offices  of 
the  Assistant  Secretary  of  Defense  (ASD)  for  C3I,  for  Developmental  and 
Operational  Testing  &  Evaluation  (DOT&E)  and  for  Program  Analysis  & 
Evaluation  (PA&E).  As  the  following  will  show,  the  principal  OSD  players  were 
influenced  by  the  dictates  of  their  positions. 

The  driving  force  behind  the  interest  in  MCS  in  each  of  these  offices  was 
the  portion  of  defense  acquisition  directives  and  instructions  (DODD  5000. 1 
and  DODI  5000.2  and  5000. 2-M)  which  defined  the  offices  specific  areas  of 
responsibility.  These  offices,  armed  with  the  pertinent  regulatoiy  mandates 
and  guidelines,  proceeded  to  vivisect  the  MCS  program.  The  irony  of  this 
process  is  that  compliance  with  the  letter  of  regulation  was  the  holy  grail.  The 
Army’s  need  for  the  system  was  apparently  not  relevant.  Equally  important 
(and  also  not  considered  relevant  by  OSD)  was  the  fact  that  the  regulations  are 
written  for  the  acquisition  of  hardware,  not  software  systems  such  as  MCS. 

The  argument  that  procedures  that  make  sense  for  the  acquisition  of  hardware 
may  not  universally  apply  for  software  was  not  accepted  by  OSD.11 

OSD  oversight  came  to  MCS  well  into  the  program’s  development  cycle.  By 
1992,  operational  prototypes  had  been  produced  and  plans  were  underway  to 
begin  technical  and  operational  testing.12  In  the  process  of  examining  the 
Army’s  plan  to  operationally  test  MCS,  OSD  effectively  questioned  the  Army’s 
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requirement  for  the  system  itself.  OASD-DOT&E  returned  the  Army  approved 
Test  and  Evaluation  Master  Plan  (TEMP)  without  approval.  Discussions 
between  the  author  and  the  responsible  officials  revealed  that  according  to 
OSD,  the  MCS  requirements  document  did  not  contain  the  level  of  specificity 
mandated  in  DODI  5000.2. 

DODI  5000.2  stipulates  that  requirements  documents  contain  quantifiable, 
measurable  performance  data.13  Easily  done  for  hardware  systems,  this 
requirement  is  exceedingly  difficult,  if  not  impossible,  when  the  requirements 
describe  software  designed  to  automate  the  command  and  control  process. 

The  Army  was  in  a  tough  position:  Quantify  the  improvements  that 
automation  will  make  to  a  subjective  process  or  never  gain  necessary  OSD 
approval  of  the  MCS  TEMP.  Without  an  OSD  approved  TEMP,  the  Army  could 
not  conduct  any  operational  testing  of  MCS.  Operational  testing  is  a 
mandatory  step  leading  to  a  decision  to  field.  Without  such  a  test,  the  Army 
could  not  field  the  system. 14 

While  the  Army  tried  to  determine  just  how  to  quantify  the  MCS 
requirements,  OSD  put  the  requirement  to  do  so  in  writing  in  a  6  April  1993 
Acquisition  Decision  Memorandum.15  Further  progress  toward  eventual  MCS 
fielding  was  now  delayed  until  MCS  requirements  documentation  met  with 
OSD  approved. 

OASD-PA&E  wedged  their  influence  into  the  MCS  acquisition  process  by 
issuing  a  directive  to  perform  a  full  Cost  and  Operational  Effectiveness 
Analysis  (COEA)  for  MCS.16  The  purpose  of  a  COEA  is  to  compare  and 
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evaluate  alternative  approaches  and  costs  incurred  to  meet  system 
requirements.  For  programs  under  OSD  oversight,  COEA's  are  required  prior 
to  a  decision  point  in  a  program’s  development  known  as  Milestone  1 .  The 
COEA  must  be  updated  if  required,  at  each  subsequent  decision  Milestone.17 

The  COEA  assists  in  the  Milestone  1  decision  to  proceed  to  the 
demonstration  and  validation  phase  of  a  system’s  development.  The  Army  had 
never  done  a  COEA  for  MCS  prior  to  it’s  Milestone  1  decision.  The  conduct  of 
an  informal  costing  analysis  performed  during  the  Block  2  development  was 
considered  insufficient  by  OSD.18  The  enormity  of  the  COEA  directive  lay  in 
the  fact  that  MCS  was  in  the  throws  of  preparing  for  a  Milestone  3  or 
production  decision  for  Block  3  software.  Without  any  apparent  regard  for  the 
development  status  of  the  system,  OSD  told  the  Army  to  conduct  an  analysis 
which,  if  unfavorable,  had  the  potential  to  obviate  all  the  work  and  money 
spent  on  MCS  for  the  past  ten  years.  Additionally,  OSD  made  completion  of 
the  analysis  a  pre-requisite  before  a  development  contract  for  follow-on  (Block 
4)  capabilities  could  be  let.19  Without  any  recourse,  the  Army  initiated  a  COEA 
for  MCS  in  Sept  1992. 20  Although  completion  of  the  analysis  was  set  for 
September  93,  to  date  it  has  not  been  completed. 

The  offices  within  OSD  exercising  influence  over  the  progress  of  MCS  were 
doing  so  to  meet  their  own  ends.  As  an  Army  staff  officer  involved  in  this 
process  I  frequently  found  representatives  from  one  OSD  office  totally  ignorant 
of  what  another  was  pursuing  relative  to  MCS.  As  the  Army  tried  to  continue 
MCS  development,  it  was  forced  to  respond  to  disparate  offices  of  OSD  to  alter 
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or  produce  documentation  they  and  their  regulations  required. 

The  degree  of  influence  exercised  by  these  offices  was  effectively  the  same. 
Any  problems  an  office  raised  regarding  their  piece  of  the  required 
documentation  would  slow  or  stop  development.  The  combined  result  of  the 
actions  of  OSD  finds  the  Army  continuing  to  develop  the  improvements  to  MCS 
but  progress  has  been  slowed.  Planned  operational  testing  is  now 
optimistically  projected  to  occur  in  1995,  assuming,  of  course,  OSD  approves 
the  Army  TEMP.21  Should  the  operational  test  prove  successful,  practical 
estimates  place  initial  fielding  in  early  1996.  Meanwhile  field  users  of  Block  2 
equipment  and  software  issued  in  the  late  1980’s  must  either  soldier  on  with  it 
or  choose  to  use  their  own  resources  to  purchase  commercial  equipment  in  the 
interim. 

The  other  equally  serious  result  of  OSD  oversight  is  the  potential 
represented  by  the  ongoing  COEA.  If  the  findings  of  the  study  are  unfavorable, 
the  possibility  exists  that  the  MCS  program  will  be  terminated  in  its  present 
form.  Given  this  circumstance,  fielding  projections  are  not  possible. 

Though  minuscule  considering  the  massively  complex  government 
bureaucracy,  the  friction  between  OSD  and  the  Army  over  MCS  does  fit  the 
Allison  bureaucratic  politics  model.  Governmental  action,  in  this  case  the 
slowing  and  possible  termination  of  an  urgently  needed  Army  acquisition,  is 
the  resultant  of  relatively  independent  actions  of  separate  offices  within  OSD. 
From  personal  conversation  with  some  of  the  players,  none  intended  to  stop 
the  Army  from  continuing  the  MCS  program.  Their  actions,  influenced  by  the 
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dictates  of  regulation  unfortunately  may  have  the  result  of  doing  just  that. 
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